If I type some text in Sidekick filter textbox, I see the asset tree narrows to match
the criteria. If I use mouse to choose the asset, works ok. But if I press VK_DOWN,
then a strange behaviour takes place. I travel through the invisible assets. If I
press VK_DOWN enough times, then I can highlight a visible item, but obviously invisible
items are travelled too. That makes keyboard travelling impossible.
To see the bug, load the following file and have it parsed by ctagssidekick (other
c parsers should show the same issue).
int x()
{
}
int y()
{
}
If you fill the filter with "y", and use arrows to travel through the list, you'll
notice that "x" is being travelled too.
Desired behaviour: omit invisible assets when travelling the list through keyboard.
Another similar details that could be done in the same time:
1. Pressing enter in the filter box should place the focus in asset tree.
2. When asset list is focused, I would prefer keyboard hits be serviced by asset tree,
not by filter. I would be able to quickly select the entry even with a filter on.
I like very much the behaviour of asset list when the filter is off, so it would be
good to join both functionalities: filtering and quick access by beginning letters.
Submitted | jarekczek - 2011-09-09 - 07:51:58z | Assigned | nobody |
---|---|---|---|
Priority | 3 | Category | None |
Status | Open | Group | None |
Resolution | Accepted | Visibility | No |
2011-09-09 - 08:07:30z jarekczek |
XP, 4.4.1 |
---|---|
2011-09-20 - 18:01:45z jarekczek |
Workaround: use arrows with Control |
2011-09-20 - 18:20:10z daleanson |
Do you think this is simply a documentation problem? |
2011-09-20 - 23:50:47z ezust |
I can confirm this bug. If I filter on y, and use arrow keys to travel through the
list, the cursor becomes invisible as the it hits "x", but it's definitely on one
of the filtered nodes. After another VK_DOWN, it hits "y" and cursor is visible again. |
2011-09-20 - 23:52:03z ezust |
but if we document it clearly, then it won't be a bug anymore. Perhaps this is just
how java trees work? |
2011-09-22 - 06:39:15z jarekczek |
I insist this is a bug. From next/prevLeaf the bug is removed by an additional loop.
I'm ready to apply a similar loop to next/prev, but first I reported inconsistency
between next/prevLeaf in: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3411490&group_id=588 After that resolution is accepted I'll be sure what the condition of "visibility" is. Of course I don't mind you fix it yourselves. |
2011-09-09 - 07:51:59z jarekczek |
main.c simple file with x and y functions |
---|